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SPECIAL  SECTION:  RISK  MANAGEMENT 


A  Primer  on 
Risks,  Issues  and 
Opportunities 

Thomas  L.  Conroy  II,  Ed.D. 


Risks,  issues  and  opportunities  are  program¬ 
matic  hurdles  for  many  acquisition  personnel. 
For  example,  program  offices  deal  with  tech¬ 
nical  risks  in  the  form  of  technologies  that  are 
not  mature  enough  or  are  unable  to  provide 
the  same  capability  in  production  that  was  achieved 
in  development.  They  also  deal  with  cost  risks  such  as 
an  insufficient  budget  or  budgetary  cost  overruns  and 
program  efforts  that  take  longer  than  scheduled  due 
to  requirements  growth.  The  basics  of  risks,  issues  and 
opportunities  will  be  tackled  in  this  article.  But,  first, 
let's  define  them. 

Risks  are  those  future  events  that  can  negatively  impact  a  program  either 
through  cost,  schedule  or  performance.  We  manage  risks  by  developing 
and  implementing  a  sound,  well-coordinated  risk  management  plan  and 
then  track  risks  by  plotting  them  on  a  5-by-5  risk  assessment  matrix  (see 
Figure  1).  An  important  aspect  of  risk  management  is  prioritizing  risks  to 
show  where  each  additional  dollar  spent  on  mitigation  would  make  the 
most  sense  and  give  the  biggest  return.  These  funds  come  from  within  the 
program  budget  and  thus  are  extremely  limited.  We  have  several  options 
in  handling  the  risk  in  a  program,  and  these  include  "buying  down"  risks 
with  funds  to  purchase  mitigation  efforts  that  lower  either  likelihood  or 
consequence.  A  risk  has  three  main  parts:  a  future  root  cause,  a  likelihood 
and  a  consequence.  The  future  root  cause  is  determined  through  root  cause 
analysis,  which  is  the  most  important  part  of  any  risk  management  effort. 


Conroy  is  a  professor  of  Systems  Engineering  (Test  and  Evaluation)  in  the  Capital  and  North¬ 
east  Region  of  the  Defense  Acquisition  University  at  Fort  Belvoir ;  Virginia.  He  holds  a  doctorate 
of  education. 
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Figure  1.  Risk  Reporting  Matrix  Format 


Risk  ID  #82:  Risk  Statement... 
Consequences  if  Realized: 

•  Cost— 

•  Performance— 

•  Schedule- 

Handling  Method:  (Accept,  Avoid,  Trans¬ 
fer  or  Mitigate)  Summarize  activities: 

1.  Summarize  Key  Activity  1 

2.  Summarize  Key  Activity  2 

3.  Etc. 

Planned  Closure  Date: 


Risk  ID  #23:  Risk  Statement... 
Consequences  if  Realized: 

•  Cost— 

•  Performance— 

•  Schedule- 

Handling  Method:  (Accept,  Avoid,  Trans¬ 
fer  or  Mitigate)  Summarize  activities: 

1.  Summarize  Key  Activity  1 

2.  Summarize  Key  Activity  2 

3.  Etc. 

Planned  Closure  Date: 


O  -  Original  Risk  Analysis 
#  =  Current  Assessment 
■  =  Predicted  Final 
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Risk  ID  #45:  Risk  Statement... 
Consequences  if  Realized: 

•  Cost— 

•  Performance— 

•  Schedule- 

Handling  Method:  (Accept,  Avoid,  Trans¬ 
fer  or  Mitigate)  Summarize  activities: 

1.  Summarize  Key  Activity  1 

2.  Summarize  Key  Activity  2 

3.  Etc. 

Planned  Closure  Date: 


Risk  ID  #85:  Risk  Statement... 
Consequences  if  Realized: 

•  Cost— 

■  Performance— 

•  Schedule- 

Handling  Method:  (Accept,  Avoid,  Trans¬ 
fer  or  Mitigate)  Summarize  activities: 

1.  Summarize  Key  Activity  1 

2.  Summarize  Key  Activity  2 

3.  Etc. 

Planned  Closure  Date: 


Risk  ID  #97:  Risk  Statement... 
Consequences  if  Realized: 

■  Cost— 

•  Performance— 

•  Schedule- 

Handling  Method:  (Accept,  Avoid,  Trans¬ 
fer  or  Mitigate)  Summarize  activities: 

1.  Summarize  Key  Activity  1 

2.  Summarize  Key  Activity  2 

3.  Etc. 

Planned  Closure  Date: 


Suggested  Risk  Reporting  Format  from  DoD  Risk,  Issue,  and  Opportunity  Management  Guide  for  Defense  Acquisition  Programs,  June  2015. 


Root  cause  analysis  gets  to  the  heart  of  the  risk.  Why  does 
the  risk  exist?  What  is  its  nature?  How  will  the  risk  occur? 
What  should  be  done  about  it?  All  of  these  questions  assist 
in  identifying  the  root  cause.  Risk  identification  and  analysis 
should  be  done  early  in  the  risk  management  process.  In  these 
steps,  we  determine  what  could  go  wrong,  the  likelihood  of 
the  problems,  and  how  bad  the  consequences  could  be.  The 
easiest  way  to  determine  the  root  cause  of  a  risk  is  to  break 
down  the  system  being  analyzed  into  lower-level  components 
and  then,  based  on  what  has  happened  before,  ask  what  could 
go  wrong  with  those  components. 

For  example,  let's  say  you  are  developing  a  previously  nonex¬ 
istent  kind  of  unmanned  ground  vehicle  (UGV).  If  you  break 
it  down  into  its  components,  you  will  find  that  you  have  a  lot 
of  background  information  for  performing  analysis  based  on 
the  individual  components  and  their  histories.  If  the  UGV  has 
armor,  you  can  analyze  the  armor  type  and  material  to  de¬ 
termine  what  types  of  risks  might  be  caused.  If  the  UGV  has 
a  remote  control,  you  can  analyze  the  radio  transmitter  and 
receiver  components  and  user  input  and  control  functions  to 
determine  the  risks  associated  with  those  types  of  subsystems 
and  components. 

Root  cause  analysis  is  about  predicting  the  future  likelihood 
and  consequences  of  a  particular  cause  based  on  the  data 


that  exist  about  previ¬ 
ous,  similar  cause-and- 
effect  relationships.  If 
there  have  been  simi¬ 
lar,  earlier  causes  with 
similar  consequences, 
we  can  use  various 
statistical  and  cause- 
and-effect  analyses  to 
determine  the  likeli¬ 
hood  of  those  causes 
recurring  and  produc¬ 
ing  a  similar  effect.  This 
is  why  gathering  data 
about  the  performance 
of  a  system  and  its  com¬ 
ponents  is  so  important 
throughout  a  system's 
life  cycle. 

Issues  are  simply  risks 
that  have  a  likelihood 
of  100  percent.  They 
are  no  more  or  less  im¬ 
portant  than  risks.  This 
is  important  because, 
once  it  is  understood, 
you  can  treat  risks  and 
issues  in  similar  fash¬ 
ion  and  prioritize  them 
using  the  same  criteria 
rather  than  arguing  over  whether  a  risk  is  an  issue  or  vice 
versa.  For  example,  you  may  have  a  risk  that  has  a  50  per¬ 
cent  likelihood  based  on  past  years  in  which  your  budget 
was  cut  by  15  percent.  Based  on  the  June  2015  Department 
of  Defense  Risk ,  Issue ,  and  Opportunity  Management  Guide  for 
Defense  Acquisition  Programs ,  this  would  be  a  red,  or  high,  risk 
with  a  likelihood  rating  of  3  and  a  consequence  rating  of  5.  On 
the  other  hand,  if  you  had  an  issue  that  meant  your  schedule 
definitely  will  slip  by  2  weeks,  this  would  be  a  green,  or  low, 
issue  because  it  would  rate  a  likelihood  rating  of  5  (for  100 
percent  likelihood)  and  a  consequence  rating  of  1.  Based  on 
this  situation's  analysis,  it  would  make  more  sense  to  spend 
time  and  money  mitigating  the  budget  risk  instead  of  the 
schedule  issue. 

Handling  Risks  and  Issues 

There  are  four  approaches  to  risks  and  issues.  They  are:  avoid, 
assume,  transfer  and  mitigate.  Of  these,  the  most  common 
form  is  mitigation. 

Avoiding  a  risk  or  issue  involves  avoiding  the  root  cause  of  the 
risk  or  issue.  For  example,  if  using  a  certain  type  of  fuel  has  tox¬ 
icity  risks,  then  redesigning  the  engine  so  that  particular  fuel 
type  would  not  be  used  would  avoid  the  root  cause  and  thus 
the  risk.  This  is  most  common  when  a  risk  has  an  extremely 
high  consequence  and/or  high  likelihood. 
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Assuming  the  risk  or  issue  involves  allowing  the  potential  risk 
or  issue  to  occur  because  most  likely  the  consequence  is  low 
or  acceptable.  For  example,  it  would  make  more  sense  to  as¬ 
sume  a  risk  of  which  the  consequence  was  $1,000  and  the 
mitigation  would  cost  $50,000.  It  does  not  make  sense  to 
spend  $50,000  to  save  $1,000. 

Transferring  the  risk  or  issue  involves  shifting  the  consequence 
to  another  party  or  component  by  shifting  the  root  cause 
to  that  party  or  component.  For  example,  if  you  had  a  very 
high-risk  requirement  due  to  a  low  technical  maturity  of  the 
components  needed  to  achieve  that  requirement,  you  could 
shift  the  requirement  to  the  next  increment  of  development 
to  allow  time  for  the  technology  to  mature.  There  are  caveats 
about  transferring  risks  and  issues,  in  my  opinion.  I  believe 
that  you  cannot  transfer  risk  without  transferring  responsibil¬ 
ity.  Because  of  this,  it  is  very  difficult  to  transfer  risk  to  the 
developing  contractor.  I  believe  you  can  share  risk  with  the 
developing  contractor  through  contract  incentives  and  war¬ 
ranties.  But  without  transferring  the  responsibility,  you  cannot 
fully  transfer  the  risk. 

Mitigation  of  risk  or  issue  is  the  method  I  have  seen  most 
often  used  to  handle  risks  and  issues.  For  mitigation,  we  take 
funding  from  the  program  and  use  it  to  produce  opportuni¬ 
ties  to  counteract  the  root  cause  of  the  risk  or  issue.  It  is 
most  important  that  the  mitigation  counters  the  root  cause 
and  not  the  symptom  of  the  risk  or  issue.  Otherwise  you  will 
be  spending  funds  to  plug  one  hole  in  a  sieve.  Mitigation  is 
important  to  tackle  throughout  a  program's  life  and  requires 
being  proactive  with  risk  management  early  in  the  system 
life  cycle.  Mitigation  can  be  used  to  "buy  down"  the  risk  to 
a  lower  level  such  as  red  to  yellow  and  then  possibly  green. 
It  is  important  to  try  to  lower  and  not  try  to  negate  the  risk 
with  mitigation. 

It  also  is  important  to  ensure  that  your  mitigation  has  time  to 
succeed.  For  example,  if  you  usually  leave  for  work  at  7:30  a.m. 
to  arrive  at  work  by  8  a.m.,  but  your  car  often  fails,  you  may 
use  the  bus  to  mitigate  lack  of  a  ride  to  work  (as  opposed  to 
servicing  your  vehicle).  If  the  bus  that  would  get  you  to  work 
by  8  a.m.  leaves  at  7:10  a.m.,  you  would  need  to  prepare  to 
drive  to  work  by  7  a.m.  to  allow  enough  time  to  catch  the  bus 
if  your  car  fails— not  prepare  to  leave  at  7:30  as  you  would  if 


the  car  were  dependable.  You  need  to  plan  and  schedule  for 
your  mitigation  strategy  to  allow  it  time  to  succeed. 

Opportunities 

Let's  now  discuss  opportunities,  which  are  the  positive  view 
of  planning  whereas  risks  and  issues  constitute  the  negative 
view.  Opportunities  are  dealt  with  in  a  similar  fashion  to  risks: 
We  still  use  root  cause  analysis  to  plan  for  them.  We  look  at 
opportunities  for  positive  events  to  occur  and  the  root  causes 
of  those  future  positive  events  and  prioritize  them  on  a  5-by-5 
matrix  focusing  on  likelihood  and  benefits  (instead  of  con¬ 
sequences).  The  opportunity  matrix  allows  for  prioritization 
of  opportunities  so  that  they  can  also  be  handled  for  future 
potential  benefits. 

Opportunities  are  handled  through  three  main  ways:  pursue, 
reject,  and  re-evaluate.  These  are  the  types  of  possible  action 
for  each  opportunity.  Pursuit  of  an  opportunity  means  that  you 
accept  that  the  potential  for  a  future  benefit  is  likely  enough 
to  warrant  spending  funds  to  achieve  it. 

Rejecting  an  opportunity  means  that  you  have  analyzed  the 
return  on  investment  potential  for  the  future  benefit  and  found 
that  it  does  not  warrant  the  expenditure.  This  could  mean  ei¬ 
ther  that  the  return  on  investment  or  that  the  likelihood  of 
success  is  too  low.  Either  way,  it  would  be  a  bad  investment. 

Re-evaluating  an  opportunity  requires  focusing  on  continually 
evaluating  the  potential  for  success  over  time.  It  means  allow¬ 
ing  more  data  to  be  gathered  and  allowing  the  likelihood  for 
success  to  grow  over  time  until  the  return  on  investment  looks 
worthy  of  funding  and  success  seems  achievable. 

Summary 

I  think  there  are  many  exciting  ways  to  deal  with  risks,  issues 
and  opportunities  for  programs  today.  The  methods  are  sound 
when  approached  responsibly.  It  is  up  to  every  member  of 
a  program  office  to  support  the  risk,  issue  and  opportunity 
management  processes  and  learn  from  the  Department  of  De¬ 
fense  Risk ,  Issue ,  and  Opportunity  Management  Guide  for  Defense 
Acquisition  Programs ,  as  well  as  the  best  practices  and  lessons 
learned  in  other  programs.  & 

The  author  can  be  contacted  at  tom.conroy@dau.mil. 
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